Packet processing systems utilize network routing or switch integrated circuits (ICs) to forward packets from input or ingress ports to output or egress ports. In particular, these integrated circuits are able to forward network packets from an ingress port to one or more egress ports based upon information contained within selected fields within the input packets. This information can include user identification information, such as source and destination address information, as well as other information. However, for mobile user devices within a communication system, such as a system that uses the GPRS tunneling protocol (GTP) for packets, the device identification information for user equipment can change as the mobile user equipment moves within the communication system. For example, when a mobile handset moves from being serviced by one base station to another base station within a cellular communication network, the identification information for that mobile handset will often change as the handover occurs between the two base stations.
Network analysis tools are used within communication networks to monitor network traffic and to detect events, such as undesired network intrusions. When multiple network analysis tools are being utilized in parallel to monitor network traffic, it is often desirable to load balance the network traffic among the network analysis tools. Further, network analysis tools often desire to receive all packets associated with a particular communication session for a mobile user device in order to enhance the ability of the network analysis tool to provide effective monitoring of the network traffic. For example, as mobile user equipment moves through a communication network, it is desirable for all the network traffic associated with that user equipment to be identified and forwarded to the same network analysis tool. Currently, however, this result is difficult to achieve, if not impossible, for load balanced systems when mobile user devices move between base stations, particularly within a GTP-based system or other communication systems that utilize a tunneling protocol for packet communications within the communication system.
FIG. 1 (Prior Art) is a block diagram of an embodiment 100 for a communication system including a traditional network tool load balancer 102. The communication system depicted includes three base stations (BS1, BS2, BS3) 112, 114, and 116 and is designed in part for use with mobile user devices. As depicted, first user equipment (UE1) 108 and second user equipment (UE2) 110 are users within the communication system and are mobile within the communication system. Base station (BS1) 112 and base station (BS2) 114 are coupled to a first radio network controller (RNC1) 118. Base station (BS3) 120 is coupled to a second radio network controller (RNC2) 120. The two radio network controllers (RNC1, RNC2) 118 and 120 are coupled to gateway 122, which is in turn coupled to an internet gateway (IGW) 128. The IGW 128 provides packet communications to and from the internet 134. Further it is noted that additional base stations, radio network controllers, gateways, and internet gateways can be provided within the communication system, as desired. For example, additional gateways 124 and 126 are depicted that can be connected to additional base stations and radio network controllers, and additional internet gateways 130 and 132 are also depicted that can be coupled to these additional gateways and the internet 134.
For the embodiment depicted, the load balancer 102 receives network packets from three passive network taps represented by a first tap (TAP1) 140, a second tap (TAP2) 142, and a third tap (TAPS) 144. The load balancer 102 is coupled to a first network tool (TOOL1) 150 through connection 151, a second network tool (TOOL2) 152 through connection 153, and a third network tool (TOOLS) 154 through connection 155. The network analysis tools 152, 154, and 156 are also coupled to a user equipment (UE) session off-line post-processor 160. The UE session off-line post-processor 160 is used to post-process mobile communication traffic and to analyze UE sessions due to the inability of the load balancer 102 to identify and separate UE sessions in real-time. Post-processing is required to determine which packets belong to which UEs, and these packets can be spread across different network tools.
It is noted that FIG. 1 (Prior Art) represents a simplified version of a mobile communication system, such as an LTE (Long Term Evolution) communication system that utilizes GTP-based packets, and many more users, base stations, RNCs, gateways, and/or other infrastructure would be included in an actual mobile communication system implementation. As such, many more interfaces and communication links would likely be tapped and/or monitored within the system. The load balancer 102, therefore, would likely receive significantly larger number of packet streams from taps and monitors than the three taps (TAP1, TAP2, TAP3) 140, 142, and 144 represented in FIG. 1A (Prior Art). As the numbers of user sessions and related packets grow, the post-processing required by UE session off-line post-processor 160 becomes significant and more complex.
The inability of load balancer 102 to perform real-time determination of the UE source can be further explained by looking to the UE communications within embodiment 100 as the UEs move between base stations. Looking first to the first user equipment (UE1) 108, UE1 108 is depicted as moving between being serviced by the third base station (BS3) 116 to being serviced by the second base station (BS2) 114, as indicated by the arrow 107. Initially, therefore, packets from UE1 108 are received by BS3 116 and sent to RNC2 120 through connection 117. The UE1-3 designation for connection 117 represent a packet stream associated with UE1 108 for a communication session. These UE1-3 packets are then forwarded by RNC2 120 to gateway 122 through connection 121. From the gateway 122, these packets make their way to the Internet 134 through IGW 128. Return packets can travel back through the IGW 128, gateway 122, RNC2 120, and BS3 116 to be received by UE1 108.
When the UE1 108 moves within the communication system according to arrow 107, however, a handover can occur from BS3 116 to BS2 114. Once this occurs, BS2 114 now services packet communications with UE1 108. As such, packets from UE1 108 are now received by BS2 114 and are provided to RNC1 118 through connection 115, as indicated by the UE1-2 designation. These packets are then forwarded by RNC1 118 to gateway 122 through connection 119. From the gateway 122, these packets can make their way to the Internet 134 through IGW 128. Return packets can travel back trough the IGW 128, gateway 122, RNC1 118, and BS2 114 to be received by UE1 108.
Looking next to the second user equipment (UE2) 110, UE2 110 is depicted as moving between being serviced by the first base station (BS1) 111 to being serviced by the second base station (BS2) 114, as indicated by the arrow 109. Initially, therefore, packets from UE2 110 are received by BS1 112 and sent to RNC1 118 through connection 113. The UE2-1 designation for connection 113 represents to packet stream associated with UE2 110. The UE2-1 packets are then forwarded by RNC1 118 to gateway 122 through connection 119. From the gateway 122, these packets make their way to the Internet 134 through IGW 128. Return packets can travel back trough the IGW 128, gateway 122, RNC1 118, and BS1 112 to be received by UE2 110.
When the UE2 110 moves within the communication system according to arrow 109, however, a handover can occur from BS1 112 to BS2 114. Once this occurs, BS2 114 now services packet communications with UE2 110, as well as packet communications with UE1 108. As such, packets from UE2 110 are now received by BS2 114 and provided to RNC1 118 through connection 115, as indicated by the UE2-2 designation. These packets are then forwarded by RNC1 118 to gateway 122 through connection 119. From the gateway 122, these packets can make their way to the Internet 134 through IGW 128. Return packets can travel back trough the IGW 128, gateway 122, RNC1 118, and BS2 114 to be received by UE2 110.
The movement of the UE1 108 and UE2 110 make it difficult to determine the particular source for the different packet streams UE1-3, UE1-2, UE2-1, and UE2-2. As UE1 108 and UE2 110 move and are handed over to different base stations, the identity information for UE1 108 and UE2 110 within transmitted packets will change. These identification changes and differences will cause the network tool load balancer 102 to be unable to determine the source of the packets. In particular, the different packet streams (e.g., UE1-3, UE1-2, UE2-1, and UE2-2) will look to the load balancer 102 as if they are unassociated packet streams.
When load balancer 102 balances network traffic among the network tools (TOOL1, TOOL2, TOOL3) 150, 152, and 154, the load balancer 102 will do so without recognizing that the different packet streams for UE1 108 and UE2 110 are from the same source device. As depicted, load balancer 102 has balanced the different packet streams by providing packet stream UE2-1 to first network tool (TOOL1) 150, by providing packet stream UE1-3 to second network tool (TOOL2) 152, and by providing packet streams UE1-2 and UE2-2 to third network tool (TOOL3) 154. These tools 152, 154, and 156 will then process these packet streams as separate packet streams.
Because of the inability of the load balancer 102 to identify the source of the input packets, a UE session off-line post-processor 160 is required to determine which packets belong to which UE. The post-processor 160 performs off-line post-processing of the packets received by all three tools 152, 154, and 156 to try to determine source identification information and match different packet streams or sessions with particular UEs. This post-processing, however, is complex and cumbersome, and it yields after-the-fact results that are not helpful for real-time monitoring of mobile network traffic.
In an effort to track user identity within a communication system having mobile user devices that move within the system, a hash function technique has been applied in prior solutions to identify user devices. For this technique, a hash function is applied to fields within a packet, and the result of the hash function is used to direct packets to an output or egress port. For example, a hash function can be applied to identification fields within packets, such as source/destination IP addresses, tunnel endpoint identifiers (TEID), UDP (user datagram protocol) port identifiers, and/or other packet identification fields. The resulting hash values are then stored as user identifiers and used to direct future packets to common egress ports. This hash function technique, however, does not keep track of changes in UE identification information due to mobility of the UE within the communication system. Thus, where IP addresses, TEIDs, and/or other identification information change for UEs that travel across geographic/coverage areas, such as UE1 108 and UE2 110 above, the hash function technique will fail to deliver new packets for a particular user to the same egress tool part as previous packets.
Other solutions have applied active in-line load balancers that identify user devices. This active in-line load balancing technique uses a small number of control plane packets to select one of multiple gateways to process packets. In-line load balancers that can be used for this technique include, for example, SSGN (serving GPRS support node) load balancers and GGSN (gateway GPRS support node) load balancers. This in-line balancing technique is only useful, however, where the load balancer can be placed in-line with the actual user traffic. This approach looks at create session requests within the in-line traffic. Upon receiving these requests, the in-line load balancer selects a new gateway processor. Subsequent communications then occur between the chosen gateway and the source. For passive monitoring devices, however, a load balancer cannot change the destination gateway, for example, of a GTP (GPRS tunneling protocol) session. As such, this prior active in-line load balancing technique is not useful for passive monitoring applications.